feat: ownership oracles (externally computed reviewer requirements) - #178
feat: ownership oracles (externally computed reviewer requirements)#178zbedforrest wants to merge 9 commits into
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces 'Ownership Oracles' (computed ownership) to Codeowners Plus, allowing external tools to feed JSON-based reviewer requirements into the action. The changes include adding the oracle-files input, parsing and merging oracle rules with standard .codeowners requirements, and introducing the pkg/oracle package with accompanying tests. The review feedback focuses on improving robustness in pkg/oracle/oracle.go by validating glob patterns during parsing to fail-closed, and adding nil checks for warningWriter and overlays in Merge to prevent potential panics.
ddcf8b6 to
5b75238
Compare
zbedforrest
changed the title
5b75238 to
dbb86fe
Compare
zbedforrest
changed the title
…eviewer requirements)
dbb86fe to
980c869
Compare
- Parse rejects leading-slash patterns, which are valid per doublestar but silently never match repo-relative diff paths - Parse rejects whitespace-only owners, not just empty strings - MergeCodeOwners no longer treats optional-only reviewers as conferring ownership, so an optional oracle rule cannot suppress the unowned-file warning (matches .codeowners semantics) - README: guidance on protecting the oracle generator script from PR tampering, and clarified ownership notes
|
Codeowners approval required for this PR: |
BakerNet
left a comment
BakerNet
left a comment
There was a problem hiding this comment.
I am completely good with Oracles as presented - but I think the important question is:
Do want a model of overriding ownership rules at the start of the process (ownership Oracles as presented) or do we want a plugin system with a set of hooks at different stages of the COP lifecycle?
This would me more flexible to do the kinds of changes @asyncawaitpromise had in mind (e.g. filtering "trivial" changes out of diffs being analyzed) but also eliminates this design decision:
Add-only: oracle rules can add requirements but never remove or weaken .codeowners rules, so a tampered oracle file can at worst request extra reviews.
2 participants
Related PR(s)
#179 builds on this (inline ownership). Supersedes the seam explored in #45.
Summary / Background
Some ownership requirements depend on what changed inside a file, not which file changed (e.g. "telemetry event schema changes need data-platform review"). Path patterns can't express that, so such policies live in advisory bots that comment on PRs but enforce nothing.
This PR adds ownership oracles: an earlier workflow step computes reviewer requirements from the PR's content and hands them to codeowners-plus as a JSON file via the new
oracle-filesinput. The rules are AND-merged into.codeowners-derived ownership through the existingMergeCodeOwnerspath, so review requesting, approval tracking, smart dismissal, and the status check apply unchanged.Design properties:
.codeownersrules, so a tampered oracle file can at worst request extra reviews.Code Changes
pkg/oracle: JSON rule format,Parse/Loadwith strict validation,RuleSet.ToCodeOwnerspkg/codeowners:NewFromFileOwnersconstructor for computed ownershipinternal/app:applyOraclesmerge step;main.go/action.yml:oracle-filesinputsplitOracleFiles